1. Technical Field
The present invention relates to an improved data processing system. In particular, the present invention relates to a session initiation protocol application in a data processing system. Still more particularly, the present invention relates to a framework for session initiation protocol application design, development, execution, and integration in a data processing system.
2. Description of Related Art
Session initiation protocol (SIP) is a signaling protocol for Internet conferencing, telephone, presence, event notification, and instant messaging. SIP was developed within the Multiparty Multimedia Session Control (MMUSIC) working group and issued by the Internet Engineering Task Force (IETF).
SIP allows disparate computers, phones, televisions, and software to communicate via SIP messages. The structure of a SIP message is similar to a hypertext transfer protocol (HTTP) message, but with an addressing scheme similar to simple mail transfer protocol (SMTP). Using SIP, users of the Internet may locate and contact one another regardless of media content and number of participants. SIP negotiates sessions, such that all participants may agree on and modify session features. Through SIP, participants may also add, drop, or transfer users.
When a user, user A, attempts to communicate with another user, user B, within the same domain using the same service provider, user A notifies a SIP proxy server of the identity of user B. Users A and B may use different media to communicate, for example, user A may use a SIP phone and user B may use a personal computer running a soft client that supports voice and video. The SIP proxy server then asks for and receives user B's internet protocol (IP) address from the SIP registrar server. SIP registrar server is a database that contains locations of all the users within a domain.
After the SIP proxy server receives the IP address of user B, the SIP proxy server relays user A's invitation to communicate with user B, including the medium or media user A is using. User E then informs the SIP proxy server that user A's invitation is acceptable and that he or she is ready to receive the message. Once the proxy server forwards user B's acceptance to user A, the SIP proxy server communicates the acceptance to user A, and thus, establishes the SIP session. Users A and B may then create a point-to-point connection using a communication protocol, such as real time protocol (RTP).
If user B is in a different domain, meaning that user B is using a different service provider, the SIP proxy server of user A recognizes that user B is in a different domain and queries the SIP redirect server for user B's IP address. SIP redirect server allows SIP proxy servers to direct SIP sessions to external domains and the SIP redirect server may reside in either or both domain A or B.
The SIP redirect server feeds user B's IP address back to the SIP proxy server, which in turn forwards the SIP session invitation to SIP proxy server in user B's domain. The SIP proxy server in user B's domain then delivers user A's invitation to user B, who forwards his or her acceptance along the same path the invitation traveled.
While SIP provides a flexible scheme for communication between different types of users, SIP applications have a number of disadvantages. One disadvantage of SIP applications is that developers of SIP applications often find it difficult to track SIP interactions as the complexity of SIP applications grows. SIP applications require developers to maintain application state and lifecycle, as well as execution flows, between different users. For example, if a two party call is joined by a third party, communication paths between parties increase as a result. This becomes a tedious task for developers of SIP applications, since state transitions between users also increase.
Another disadvantage is that current SIP applications provide no modeling capabilities for the developers. Thus, developers may not use modeling tools to model the application execution flow, to provide documentation, or structure the application architecture. Furthermore, SIP applications do not support business process elements that are outside of the SIP applications and do not execute in parallel with these elements. Thus, there is no connection between outside business process elements and infrastructure elements of SIP applications.
While some SIP application providers provide remote method invocation extensions for communication with SIP applications that are running on an application server, there is no existing mechanism within SIP applications that directly integrates with outside business elements. Moreover, developers may want to allow users to generate customized SIP applications. In this way, the users may interact with the SIP application directly, via Web forms or applications, in order to specify a list of options desired in the SIP application.
Therefore, it would be advantageous to have an improved method, apparatus, and computer instructions for a framework for SIP application design, development, and execution, such that application complexity may be reduced, which leads to simplified programming effort. It would also be advantageous to have an improved method that provides modeling capabilities to developers, integrates with outside business process elements, and allow users to generate customized SIP applications.